COMMENT ⊗   VALID 00017 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	IMPSER documentation				MRC 5/9/79
C00005 00003	IMP interface I/O programming:
C00008 00004	IMP-Host Protocol:
C00013 00005	Host-Host Protocol:
C00017 00006	Host-Host Protocol opcode definitions (from NIC 8246 and NIC 30490):
C00021 00007	Host-Host Protocol error codes:
C00024 00008	IMP user mode programming:
C00027 00009	IMP I/O status word:
C00030 00010	IMP MTAPEs:
C00033 00011
C00035 00012	Host number specification:
C00038 00013	Socket assignments:
C00041 00014	User messages:
C00043 00015	NCP operation messages:
C00045 00016	IMP-Host Protocol messages:
C00048 00017	Host-host Protocol messages:
C00054 ENDMK
C⊗;
IMPSER documentation				MRC 5/9/79


     Before even trying to understand IMPSER, you should be familiar
with what's in BBN Report 1822, Specifications for the Interconnection
of a Host and an IMP; and NIC 7104, ARPAnet Protocol Handbook (at
least the Host-Host protocol).  You should also read the UUO manual,
section 12.14, on user mode I/O programming for the IMP.  This
document has brief summaries, but it is no substitute for the real
thing.

     Now that you understand all of this completely, you're now ready
to read the rest of this document.
IMP interface I/O programming:

     The IMP interface is device 400, mnemonic IMP.

     I/O to the IMP is done via DATAI and DATAO.  In 32. bit mode
the byte is returned left-adjusted in the word.

     "stop" means enable "wait".  "wait" happens after the last bit
has come in (if enabled by "stop") to allow the programmer to change
data modes before the first bit of the next word comes in.


CONI IMP,bits

Bit	Name	Meaning

2.9	TYHB	There's Your Host Bit
2.8	RFNHB	Ready For Next Host Bit
2.7	TEST	Interface is in test mode
2.6	IMPERR	IMP error (the READY line has gone down)
2.5	IDONE	Input done
2.4	IEND	Input end (end of message)
2.3	ODONE	Output done
2.2	¬READY	IMP not ready if ¬TEST (actually ¬TEST∧¬READY)
1.9→1.7	IEPIA	input end PI channel
1.6→1.4	IDPIA	input done PI channel
1.3→1.1	ODPIA	output done PI channel


CONO IMP,bits

Bit	Name	Meaning

2.7	TEST	Enter test mode.  In test mode the output side is
		 tied to the input side of the interface, and READY
		 is brought down
2.6	STRIN	Start input, sets stop, clears IEND
2.5	I32	Set 32. bit input mode if IDPIEN set
2.4	O32	Set 32. bit output mode if ODPIEN set
2.3	CLRST	Clear stop
2.2	CLRWT	Clear wait
1.8	STROUT	Start output
1.7	FINO	Finish output (last bit has been sent)
1.6	IEPIEN	Enable change of IEPIA
1.5	IDPIEN	Enable change of input byte size and IDPIA, clear
		 IMPERR
1.4	ODPIEN	Enable change of output byte size and ODPIA
1.3→1.1	PIA	PI channel (see IEPIEN, IDPIEN, ODPIEN)
IMP-Host Protocol:

     The protocol is in about 3 layers.  The first layer is IMP-HOST
protocol.  The IMP sends us each message prefaced by a 96-bit leader
which looks like this:

1   4 5        8 9          16 17 20   21    22     24 25           32
**********************************************************************
******   NEW    * DESTINATION *******       * LEADER *    MESSAGE    *
******  FORMAT  *   NETWORK   ******* TRACE * FLAGS  *     TYPE      *
******   FLAG   *             *******       *        *               *
**********************************************************************

33            40 41         48 49                                   64
**********************************************************************
*  HANDLING     * DESTINATION *            DESTINATION               *
*    TYPE       *    HOST     *                IMP                   *
*               *             *                                      *
**********************************************************************

65               76 77      80 81                                   96
**********************************************************************
*                  *          *                                      *
*    MESSAGE-ID    * SUB-TYPE *           MESSAGE LENGTH             *
*                  *          *                                      *
**********************************************************************

     Bits 1→4 and 17→20 are unassigned and must be zero.  Bits 5→8 are
the new format flag and must be 15.  This allows the receiver to
distingush between new-style and old-style leaders.  Bit 21 is the
trace bit.  We ignore messages with this bit.  Bit 22 is a flag for us
which we ignore; bits 23 and 24 are unassigned.  Bits 25→32 are the
message type.  It tells us what to do with the message we got.
Regular messages are type 0.  Types 1, 7, 8, 9, and 10 are errors of
various kinds.  Type 2 is a warning that the IMP is going down, type 4
is no-op, type 6 is dead host status, and type 11→14 are for the
legendary non-blocking host interface.  All other types are currently
unassigned.

     Bit 33 is the priority message bit.  We set it on INS and INR
messages we send.  The other bits of the handling type are unused.
The host and IMP are obvious.  The high order 8 bits of the message
id are the link number; the low order 4 bits must be zero.  The link
number is used extensively in the host-host protocol.  The sub-type
means various random things.  We never set the message length and
we always ignore it.
Host-Host Protocol:

     The second level protocol goes as follows. When a connection is
open, there is a unique host-link number associated with each
direction of communication.  Messages go back and forth as regular
messages.  Opening and closing connections is the hard part.  All
"control" messages, that is messages regarding opening and closing and
regulating connections themselves, go on link zero.  Most of these
commands have some identifying field that tells what connection they
are talking about.  Opening and closing a connection (before the
unique link number is assigned) is done with the codes STR, RTS, and
CLS and carry along what are called socket numbers. These numbers are
32-bits long.

     To establish a connection, you need a foreign socket number to
connect to.  There is defined to be at each site a LOGGER, listening
to public sockets, which returns a socket number for you to connect
to.  To open a connection, you send a STR or a RTS, depending on
whether you are sending or receiving.  These operations carry a local
socket number and a foreign socket number and one additional byte,
which is a connection byte size if RTS and a link number if STR.  A
connection is open when STR and RTS with matching socket numbers have
been exchanged.  A connection is half-duplex.  To get transmission
both ways, you need to open two connections.  The usual way is to open
a connection on the socket number you get from the LOGGER and on that
number plus one.

     A connection may be changed in at least two ways. The simplest is
the reset (RST).  A host receiving a reset is supposed to break all
connections to the host sending the reset.  The receiving host is to
return a reset REPLY (RRP) as well.

     The graceful way to break a connection is to send a close (CLS)
with the pair of socket numbers.  The host receiving the CLS is to
return a CLS with the same socket numbers in it and cause the
connection to be broken. The connection is not broken until CLSs have
been exchanged.

     When a connection is open, the receiver sends the sender an
allocate message (ALL) telling the sender how much buffering he has
available.  Every time the sender sends a message, he decrements this
number.  Each time the sender receives an allocate operation, he adds
the new allocation into the current allocation.
Host-Host Protocol opcode definitions (from NIC 8246 and NIC 30490):

NOP	0	No-Operation.

RTS	1	Establish connection, sent from Receiver To Sender.
		Followed by 32 bit receive socket, 32 bit send
		socket, and 8 bit of link number.

STR	2	Establish connection, sent from Sender To Receiver.
		Followed by 32 bit of send socket, 32 bit receive
		socket, and 8 bit byte size.

CLS	3	Close connection.  Followed by 32 bit local socket
		number and 32 bit foreign socket number.

ALL	4	Allocate, sent from receiver to sender telling how
		much data may be sent at a time.  Followed by
		8 bit link number, 16 bit message allocation and
		32 bit bit allocation.

GVB	5	Give Back allocation, sent from receiver to sender
		to request return of storage.  Followed by 8 bit
		link number, 8 bit 7-fixed-binary-place fraction
		which is the fraction of the message space to be
		returned, and 8 bit fraction which is the fraction
		of the bit space to be returned.

RET	6	Return storage, sent from sender to receiver either
		spontaneously or in response to a GVB command.
		Followed by 8 bit link, 16 bit message space, and 32
		bit bit space.

INR	7	Interrupt by Receiver, asks the sender to cease.
		Followed by 8 bits of link number.

INS	10	Interrupt by Sender, tells receiver to interrupt
		receiving process.  A special character is included
		in the text stream to mark where in time the interrupt
		is to occur.  Followed by 8 bit link number.

ECO	11	Echo test.  Followed by 8 bit test data.  Receiving
		host is to return said data verbatum via following
		command:

ERP	12	Echo Reply.  Followed by 8 bit returned test data.

ERR	13	Error.  Followed by 8 bit error code and 80 bit
		error data.

RST	14	Reset.  Asks host to clear all tables and connections
		having to do with us.

RRP	15	Reset Reply.  Indicates the reset has been done.

RAR	16	Reset Allocation by Receiver.  Indicates the RAS has
		been done.

RAS	17	Reset Allocation by Sender.  Tells the receiver to
		clear allocations.

RAP	20	Reset Allocation Please.  Sent from receiver to sender
		to ask it to send an RAS.

NXR	21	Non-existent Receive link.  Tells sender the link it
		used is non-existant (eg, data message).

NXS	22	Non-existent Send link.  Tells receiver the link it
		used is non-existant (eg, ALL).
Host-Host Protocol error codes:

ILO	1	Illegal Opcode.  An illegal opcode was detected in
		a control message. The "data" field contains the
		ten bytes of the ailing control message beginning
		with the byte containing the illegal opcode.

SPS	2	Short Parameter Space.  The end of a control message
		was encountered before all the required parameters of
		the control command being decoded were found.  The "data"
		field contains the command in error.

BDP	3	Bad Parameters.  Erroneous parameters were found
		in a control command.  Data field contains ailing command.

NES	4	Non-Ex Socket.  A command other than STR or RTS was
		received for a connection for which no request for
		connection has been made.

NOS	5	Non-Open Socket.  A command other than STR or RTS was
		received for a connection which is not completely open.

LNC	6	Link Not Connected.  Control command containing
		a link number for which no connection exists.

IHH	7	Invalid Host Header.  Non-zero M1/M2, invalid byte size,
		undersized control message, etc.

     When the error code is zero, the next 8 bit byte is the Stanford
peculiar error code, followed by 72 bits of the ailing command
returned.  Here are the Stanford error codes.

CTO	1	Counter Overflow.  Either message space exceeded
		or bit space exceeded by the last message. The
		message was discarded.

IBS	2	Illegal Byte size for control message.  Message
		was discarded.

IGN	3	Illegal Gender (Anita Bryant feature--sockets must
		be heterosocketual, ie. odd to even and even to odd)

IER	4	Illegal Error.  Host sent us an ERR for no good reason.
IMP user mode programming:

     The IMP controlling UUOs are MTAPE UUOs.  The address of the
MTAPE points to a block.  The first word of the block is the function
code that determines what to do and how to interpret any other words
in the block.  The second word is often a status bits word for the
connection.

     Status bits are in the form:

1.1 → 1.6  MTAPE error code:
	1 → socket in use
	2 → can't change socket
	3 → IMPSER bug; RTS&STR but no DDB
	4 → no links available; LNKTAB is full
	5 → illegal byte size
	6 → NCP dead
	7 → gender mismatch (more of the Anita Bryant feature)

1.7 → 2.9  When dead host expected back up, in GMT:
	7776 means unknown, 7777 means over a week from now.  Otherwise:
	1.7 → 2.1 minutes/5
	2.2 → 2.6 hours
	2.7 → 2.9 day of week (Monday = 0, etc.)

3.1 → 3.4  Why host is down
	0 → unknown
	1 → host took ready down without saying why
	2 → host is tardy
	3 → host doesn't exist
	4 → NCP initialization
	5 → scheduled PM
	6 → scheduled hardware work
	7 → scheduled software work
	10 → emergency restart
	11 → power outage
	12 → software breakpoint
	13 → hardware failure
	14 → not scheduled up
	17 → coming up now (ie, still down, but after expected up time)

3.5 → 3.8  Why host is inaccessible:
	0 → destination IMP unreachable
	1 → destination host dead
	3 → communication with this host is prohibited (naughty!)

4.3  This connection has been pawed over by the logger.

4.4  This connection has been pawed over for flushing by the half-closed
      connection flusher.

4.5  CLS received on this connection

4.6  CLS sent on this connection

4.7  RFC received on this connection

4.8  RFC sent on this connection

4.9  Connection state has changed
IMP I/O status word:

1.1 → 1.4  Data mode

1.7  BLOK    The connection is blocked in either a RFNM or allocation wait.

1.8  TMO     A timeout condition occured.  The connection has been closed
	or the connection attempt aborted.

1.9  RSET    A reset condition occured (the remote host told us to purge our
	tables).  The connection has been closed or the connection attempt
	aborted.

2.1  CTROV   The remote host sent more messages and/or bits than we allocated
	it.  The connection has been closed.

2.2  HDEAD   A host dead condition occured.  The connection has been closed
	or the connection attempt aborted.

2.3  ICTRAN  An incomplete transmission occured on the last message sent
	on this connection.  The connection has been closed.

2.6  IODEND  Connection is closed and there is no more input data to read.

2.7  IODTER  Somebody is dead.  See the other error status for what.

2.8  IODERR  Almost all IMP errors set this bit.  See the other error status
	for what is really wrong.

2.9  IOIMPM  Attempt to do IMP I/O without connecting first.

4.2  CLSW    Close wait.  One close has been sent.

4.3  RFCW    Wait for RFC; listening or connection requested

4.4  INPW    Input wait

4.5  ALLW    Allocation wait

4.6  BLOKW   Waiting for link to become unblocked

4.7  LNK0W   Control link wait
IMP MTAPEs:

FUNCTION=0		CONNECT
	1		Status bits are placed here upon return
	2		Local socket number.  -1 means gensym a receive socket
	3		Wait flag.  -1 for wait for connection
	4		Byte size, or if sending, byte size is stored here
	5		Foreign socket number
	6		Host number

FUNCTION=1		LISTEN
	1		Status bits are placed here
	2		Local socket number
	3		Wait flag
	4		Byte size of connection.  Stored here if send socket
	5		Foreign socket number returned here
	6		Host number returned here

FUNCTION=2		STATUS
	1		Status bits are placed here for send side
	2		Receive side status bits are placed here

FUNCTION=3		TERMINATE
	1		Status bits are placed here
	2		Local socket number
	3		Wait flag

FUNCTION=4		WAIT
	1		Status is returned here
	2		Local socket number

FUNCTION=5		GET TABLE ADDRESSES
	1		IMPDIE,,IMPDEA	NCP up status
	2		NMESIN,,NMESOU	NCP I/O statistics
	3		IMPTDN,,IMPTUP	IMP expected down/up time
	4		IMPDWY,,FFLNK	IMP down reason, # of links
	5		LNKTAB,,IMPDDB	Host/link #, DDB
	6		 IMPLS,,IMPFS	Local, foreign socket
	7		 IMPBS,,IMPSTB	Byte size, status word

FUNCTION=6		WAKEUP PROCESS (int level only)

FUNCTION=7		GET LISTEN INFO
	1		Status bits are placed here
	2		Local socket number (required argument)
	3		unused
	4		Byte size of connection returned here
	5		Foreign socket number returned here
	6		Host number returned here

FUNCTION=10		SKIP IF INPUT PRESENT

FUNCTION=11		SEND INTERRUPT
	1		Status bits returned here
	2		Local socket number

FUNCTION=12		BRING NCP UP (requires UPG)

FUNCTION=13		BRING NCP DOWN (requires UPG)

FUNCTION=14		TEST AND CLEAR INTERRUPT BITS
	1		Send side.  0 for no int, -1 for int present
	2		Receive side.  0 for no int, -1 for int present

FUNCTION=15		SET ALLOCATIONS
	1		Function code.  0 normal, 1 system max, 2 min
	2		Number of bits of allocation
	3		Number of messages of allocation

FUNCTION=16		RETURN ALLOCATIONS
	1		Number of bits we have allocated him
	2		Number of messages we have allocated him
	3		Number of bits he has left
	4		Number of messages he has left
	5		Number of bits in free storage
	6		Number of messages in free storage
	7		Number of bits he has allocated us
	10		Number of messages he has allocated us

FUNCTION=17		SET TIMEOUTS
	1		Word of 6-bit bytes.  Gives number of 2-second units
			for timeouts on CLS, RFNM, ALL, RFC, or INP;
			0 means wait indefinitely.

FUNCTION=20		GET TIMEOUTS
	1		Current timeout word will be placed here

FUNCTION=21		GENSYM SOCKET
	1		Gensymmed receive socket returned here

FUNCTION=22		SEND RESET (requires UPG)
	1		Host number

FUNCTION=23		SET WHY GOING DOWN (requires UPG)
	1		Host down word:
			RH contains expected time back up in IMP format
			LH 3.1 → 3.4 contains host down reason.

FUNCTION=24		UNWEDGE CONNECTION (requires UPG)
	1		Connection index
Host number specification:

     The new-style host numbers allow addressing of the full host
capacity of the ARPAnet.  The new format has been carefully designed
to be transparent to most user programs.  In particular, while
new-style host numbers are always returned, both old and new-style
numbers are accepted.  Unless a user program makes assumptions based
on the host number being 8. bits (such as fitting in a halfword), no
conversion should be necessary.

     New-style host numbers are represented in the IMP MTAPE UUO's
as follows:

	1.1 → 1.8	Host number (bits 1.7 → 1.8 of old number)
	1.9		unused, must be zero
	2.1 → 3.7	IMP number (bits 1.1 → 1.6 of old number)
	3.8 → 3.9	unused, must be zero
	4.1 → 4.8	destination network, must be zero or 12
			(for ARPAnet)
	4.9		unused, must be zero

     The reason for the reverse order of Host and IMP number is to
allow the neat compatability hack described above to work.  Having the
order in the leader won't work, because host numbers can be zero, and
splitting up bytes (as was suggested) to have a single representation
of the host number in old and new format was just too horrible to
contemplate.

     Old style host numbers are accepted in IMP MTAPE 0 (connect). All
MTAPEs which have a host number in their block return the NEW style
host number.
Socket assignments:

     Sockets are allocated in job-relative clusters of 8 sockets.  The
gensym feature of IMPSER returns the first socket of the cluster,
called the base socket.  The NCP ensures that all the sockets in the
cluster are completely unused and are available only to the job which
did the gensym.

     Sockets 1 → 777 are considered to be public sockets.  Any job may
use any of these sockets.  Odd sockets 1 → 377 are reserved for
official ARPAnet contact socket assignments, as listed in "Assigned
Numbers" [Postel].  When an RFC arrives on a contact socket, the NCP
will attempt to fire up DSK:RFCnnn.DMP[NET,SYS] (where nnn is the
socket number, with leading zeros) as a phantom.  For example, an
incoming new TELNET protocol RFC will attempt to run RFC027.  If the
server fails to pick up the connection after a minute (this can happen
if the server doesn't exist, is broken, or the system is down and
phantoms aren't allowed to run), the NCP will refuse the connection.
Note that the server must actually perform the ICP or whatever.

     Even sockets from 2 → 776 and odd sockets from 401 → 777 aren't
assigned for anything special and may be used for private programs
which require a public socket; however, using sockets 2 → 376 is
discouraged.

     Sockets ≥1000 are private sockets, and are the sockets normally
used by user programs.  In the general ICP case, the base socket is
used as the ICP contact socket by using the gensym option of the
connect MTAPE.  The socket assigned to the user program is job
relative and is of the form:

	1000+10*((JOB-1)+n*(JOBN-1))

where JOBN is the number of jobs in the system, JOB is the user's job
number, and n is the lowest non-negative integer which will generate
an unused cluster.
User messages:

     These are messages which are given in response to errors to
user UUO's.


NCP dead, UUO at user nnnnnn

     An IMP MTAPE was given which requires the NCP to be running,
but the NCP is currently down.


Illegal socket in terminate, UUO at user nnnnnn

     An IMP MTAPE 3 was given but that socket is not open on the
same DDB as the DDB of the channel which the MTAPE was issued on.


NCP already alive, UUO at user nnnnnn

     An IMP MTAPE 12 was given and the NCP was already up.


Illegal user socket, UUO at user nnnnnn

     An IMP MTAPE 0 or 1 was given with on a private socket outside
that job's working set.


Message length inconsistant with byte size, UUO at user nnnnn

     An INPUT UUO processed a message which didn't match the byte
size of the connection.


IMP I/O without Request For Connection, UUO at user nnnnnn

     An INPUT or OUTPUT UUO was given without opening a connection
on the channel.
NCP operation messages:

     These are messages which relate to the running of the NCP and not
the IMP-Host or Host-Host protocols.


Arpanet down, n connections aborted, IMP CONI=nnnnnn

     The IMP Ready line has gone down, or the IMP interface has entered
test mode.  The NCP is bringing itself down and flushing all connections.


Arpanet up

     The IMP Ready line was down, or the IMP interface was in test
mode, but this condition has been cleared.  The NCP is reinitializing.


NCP off, user=ppn, job=job-name(job#)

     The NCP was up and the specified job is bringing it down by
issuing an IMP MTAPE 13.  IMPDIE is being set to prevent the NCP from
coming up unless an IMP MTAPE 12 is issued.


NCP on, user=ppn, job=job-name(job#)

     The NCP was down and the specified job issued an IMP MTAPE 12
to attempt to restart the NCP.  Unless the NCP was down because
IMPDIE was holding it down, this attempt will probably fail since the
NCP tries to bring itself up at clock level.


IMP interface timed out

     An IMP interface timeout occured.  This should never happen.
IMP-Host Protocol messages:

    These are messages related to the first-level protocol.


Unknown msg type, data n

     A message type was received of an unused or unimplemented type.


Illegal leader format, data n

     A message came in with something other than 17 in the format flag.
We don't believe in old-style leaders, which used this byte for the
type code.  Probably the IMP somehow thinks we are talking old-style
leaders, and the NCP will need to be cycled.  We ignore messages with
4 in this byte (old-style no-ops) since the IMP will send them to us
in case we are an old-style host.


Error in leader, data n

     The IMP detected an error in a previous Host-to-IMP message and
had to assume that the leader was garbled.  The data byte is the
sub-type of the message.


IMP going down in nnn mins for mmm mins

     The IMP is transmitting this message as a warning that it will
be going down.  The following cells are loaded with information about
the forthcoming downtime:

IMPDWY	0 → last warning or panic, down in 30 seconds
	1 → scheduled hardware PM
	2 → scheduled software reload
	3 → emergency restart
IMPTDN	Time IMP will go down, in jiffies
IMPTUP	Time IMP will come up, in jiffies


Error in data

     The IMP's Error flip-flop was set after transmission of the
leader of a message but before the end of the message.


IMP ready line dropped

     The IMP sent us an interface reset message.


RFNM with no links, host hhh/iii, link nnn

     The IMP sent us a RFNM, but there are no links active.


Spurious RFNM, host hhh/iii, link nnn

     A RFNM was received on a link that we don't believe in.


Unknown link, host hhh/iii, link nnn

     A regular message came in on a link that we don't believe in.
Host-host Protocol messages:

    These are messages related to the second-level protocol.


No DDB, host hhh/iii, link nnn

     An incomplete transmission or regular message occured on a known
and non-zero link, but there is no DDB to specify where the error or
the data is to go to.


Input with no receive side, host hhh/iii, link nnn

     A regular message occured on a known non-zero link, but there
is no receive side on the DDB for that link (ie, only a send socket
is opened).


Input with connection not entirely open, host hhh/iii, link nnn

     A regular message occured on a known non-zero link, but the
receive side on the DDB hasn't been completely open yet (ie, the
matching RFC hasn't been sent yet).


Unknown link in ctl msg, host hhh/iii, link 0, data ddd

     An unknown link was referenced in a host-host control message.
The data is the losing host-link number.


Short msg, host hhh/iii, link 0, data dd

     A host-host control message was shorter than required by the
protocol (ie, was missing a required argument).  The data is the
opcode of the losing message.


New ctl msg, host hhh/iii, link 0, data dd

     An unknown (probably new type which we don't know about yet)
type host-host control message was received.  The data is the
losing opcode.


Illegal bs in ctl msg, host hhh/iii, link 0, data dd

     An illegal byte size was specified in a host-host control
message.  The data is the losing byte size.


Illegal gender in RFC, host hhh/iii, link 0

     The host is trying to engage us in homosocketuality.  Since this
is against the laws of God and ARPA, we naturally refuse to consent
to it.


Incomplete connection, host hhh/iii, link 0

     A host-host control message was received which referenced a
a connection, but a connection of the desired gender doesn't exist.
For example, ALL with only a receive side, INS with only a send
side, etc.


RFC received but no links available, host hhh/iii, link 0

     An RFC was received, but all the available slots in the system
IMP tables are taken.


CLS on non-ex skt, host hhh/iii, link 0, data ddd

     A CLS was received on a socket we don't believe in.


type ERR from host hhh/iii, data ddd ddd...

     An ERR has been received from the foreign host.  The data is the
contents of the losing message.  The type is one of the following:

Undef		This error message is peculiar to the foreign
		host.  The first byte of the data contains the
		foreign host's own sub-type.

Ill op		We sent the foreign host a control message
		it doesn't know about.

Sh ctl msg	We sent the foreign host a message with an
		insufficient number of data bytes.

Bad param	We sent the foreign host a message with
		invalid arguments.

Non-ex skt	We sent the foreign host a message which
		referenced a socket which doesn't exist.

Non-opn skt	We sent the foreign host a message which
		referenced a socket which isn't completely
		open yet.

Non-ex lnk	We sent the foreign host a message on a link
		which it doesn't believe in.

Bad hst hdr	We sent the foreign host a message with an
		invalid host header (bad M1/M2, byte size,
		length, etc.).

Unknown		Some unknown error type.